Electronic mail (e-mail) has become an important method for communicating. E-mail systems typically include a server component (e.g., Microsoft® Exchange Server) and a client component (e.g., Microsoft® Outlook® or Microsoft® Outlook® Express). These components are typically software applications that are configured to execute on computing devices (e.g., servers, PCs, laptops, and PDAs).
Often, in order to facilitate communications, a client and server, such as the client component and the server component of an email system, agree on a communications protocol. The protocol sets out rules defining expected behavior of each party during communications, for example, the expected sequence of request and response. Remote procedure calls (RPCs) are an example of a communications protocol. By utilizing remote procedure calls a program on one computer may execute a program on a server computer. A system developer may not need to develop specific procedures for the server: the client program sends a message to the server with appropriate arguments and the server returns a message containing the results of the program executed.
Some types of e-mail servers are configured to allow e-mail to be accessed via an Internet browser client (e.g., Microsoft® Internet Explorer) rather than a dedicated e-mail client. One such system is Microsoft® Exchange Server's Outlook® Web Access feature. In these systems, the browser interacts with the e-mail server, and any functions required to be performed on the client system are performed through the browser (e.g., by downloading Javascript) or through the use of Active Server Pages or the like.
Since client and servers are often connected by networks that have low bandwidth and high latency (e.g., slow dial-up connections), many users experience undesirable delays when accessing information from the server utilizing the client server protocol. However, some of these delays may be reducible if the cause of the delay can be accurately determined. For example, if a particular unreliable or overtaxed network connection is causing packets to be dropped, a network administrator may be able to reconfigure the network to reduce congestion.
While monitoring end-to-end messaging service quality is something network administrators would like to do, they typically do not have the ability to accurately measure quality from the client's perspective. Current tools that purport to offer such functionality typically require that a separate monitoring application be deployed and maintained on each client machine to be monitored. Requiring a separate monitoring application has disadvantages. For example, a separate monitoring application typically utilizes the same resources as the monitored application. In a resource-strained client server environment, the separate monitoring application may itself contribute to degradation of service quality. In addition, some conventional separate monitoring applications monitor environment parameters only indirectly related to service quality as perceived by a user of the client, for example, monitoring an underlying protocol transport layer such as TCP/IP rather than the client server protocol itself. As a result, conventional separate monitoring applications may give network administrators the impression that performance is acceptable during periods when client users are experiencing problems.